
REMARKS 

Claims 1-7 were submitted for examination. The 
examiner objected to the specification as failing to provide 
an adequate written description of the claimed invention and 
all claims were rejected under 35 U.S.C. 112, first paragraph 
on that basis. Claims 1-4 were rejected under 35 U.S.C. 
102(b) as being anticipated by Deitel ("Operating Systems 11 ) 
and claims 5-7 were rejected under 35 U.S.C. 103 as being 
unpatentable over Deitel . 

Claims 3, 4 and 7 have been cancelled. It is believed 
the arguments below are adequate to overcome the Examiner's 
rejections in regard to the remaining claims. No new issues 
are raised and no further searching is required. 
Reconsideration and allowance of this application is 
respectfully requested. 

35 U.S.C. 112 Rejection 

The Examiner requested that specific references to the 
locations in the specification be given. 

The steps required to implement the invention are shown 
in Figs. 3A and 3B. In the specification, lines 2-9 on page 
9 explain that a KFC should be divided into phases, with 
"each phase being associated with a step or set of steps in 
KFC 300 at which a complication is possible. The appropriate 
phase identifier is included with each KFC 300 instruction 
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and is passed to SC 350 when KFC 300 is promoted." From page 
9, line 15 through page 13, line 12, the specification goes 
step by step through a KFC and discusses the possible 
scenarios for promotion. In particular, page 11, line 19 
through page 12, line 18 discuss the specific 
promotion-related steps of 336, 338, 340, 352, 360, 362 and 
364. Each disclosed step is straightforward. Demotion is 
discussed in the specification at page 13, lines 3-12 and 
shown in Fig. 3B. 

The intended readers of this disclosure are programmers 
skilled in the art of developing kernel calls and system 
calls. The design, control and uses of various types of 
system calls and fast kernel traps are known and understood 
in the prior art. The "exceptions" referred to in the 
specification are the particular events or conditions that 
interfere with normal execution in a specific system. Anyone 
qualifying as skilled in the art of operating system kernel 
programming would understand how to. program calls and traps 
and would know what the Exceptions are in the particular 
operating system environment in which that person is skilled. 

35 U.S.C. 102(b) Rejections 

Claims 1-4 were rejected under 35 U.S.C. 102(b) as 
being anticipated by Deitel. Claims 3 and 4 have been 
cancelled. 
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Claim 1 

Regarding claim 1, the Examiner states in paragraph 
5 (v) of the communication of 1/3/96 that Applicant's prior 
communication did not adequately point out the specific 
deficiencies in the Deitel reference. In this regard, the 
Examiner is referred specifically to steps (b) and (c) in 
claim 1 . 

Applicant's claim 1 involves a method for the 
interaction between kernel function calls and system calls 
during execution of a processing thread. To determine the 
possible relevance of Deitel in this regard, the equivalent 
elements in Deitel must be identified. 

The Examiner's comments in paragraph 5(i) show how the 
Examiner is applying Deitel to the claimed method. In the 
second and fourth sentences of 5(i), the Examiner states that 
Deitel 's initial interrupt processing, discussed in section 
3.9 of Deitel, is equivalent to Applicant's kernel function 
call. In the fourth sentence of 5(i), the Examiner states 
that Deitel 's "appropriate system process", to which the 
initial interrupt processing passes control, is equivalent to 
Applicant's system call. Having defined Deitel in this 
manner, the disclosure of Deitel must be examined to 
determine what method Deitel teaches for the operation and 
interaction between these two elements. 

In the third sentence of 5(i), the Examiner attributes 
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a capability to Deitel that is not supported by the Deitel 
disclosure. In the third sentence, the Examiner says "Deitel 
teaches monitoring for a complication during execution of the 
kernel function call". Since the Examiner has described the 
Deitel interrupt processing as being equivalent to the kernel 
function call, then the Exmainer is saying that Deitel 
teaches monitoring for a complication during execution of 
initial interrupt processing. Deitel does not support this 
interpretation. Both the last paragraph on page 61 and the 
last two paragraphs on page 62 make it clear that Deitel 
teaches that interrupts are disabled while the initial 
interrupt processing is underway . The second paragraph on 
page 575, referred to by the Examiner, clearly relates to 
activities during system call processing not during interrupt 
processing. 

In summary, a specific limitation not taught by the 
Deitel reference is step (b) of claim 1. 

Claim 2 

Claim 2 adds three additional steps to the method of 
claim 1. In paragraph ii, the Examiner states that Deitel 
teaches all three of these steps. Applicant disagrees. 

As for step (c) (3), the Examiner asserts that "Deitel 
teaches monitoring for a suspended state in the system call 
as nucleus functions to suspend and resume processing" . In 
support of this statement, the Examiner refers to "page 62". 
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Presumably the Examiner is referring to the words "Process 
suspension and resumption" in the summary of nucleus 
functions in 3.9.1. 

Suspending and resuming processing is well known. What 
is new in this claim is monitoring for a suspend state 
occurring during system call processing and demoting to a 
kernel function call if a suspend state is reached. Deitel 
does not teach or contemplate monitoring for a suspend state 
because it has no reason to do so. Nothing in Deitel teaches 
or suggests that any change in processing flow might ever 
take place when a system call reaches a suspend state. 

The Examiner's comment in the second sentence of 
paragraph ii is unsupported by the Deitel disclosure. In 
paragraph i the Examiner defines Applicant's kernel function 
call as being equivalent to Deitel 's interrupt processing. 
Now in paragraph ii, the Examiner is stating that Deitel 
teaches "demoting from the system call to the kernel call and 
continuing execution in the kernel function call". This, 
using the Examiner's position from paragraph i, would mean 
that Deitel teaches demoting back to the interrupt processing 
function. This is clearly not the teaching of Deitel. 
Nothing in Deitel suggests passing execution back to the 
interrupt handler once it has done its job and has passed 
processing to the "appropriate system process". 
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Claims 5 and 6 

Inherent in Applicant's idea of passing "an identifier 
indicating the amount of kernel function call execution that 
had been completed at the time the complication was detected" 
is the notion that it is possible for kernel function call 
processing to be interrupted before it has been completed. 
As noted above, the Examiner equates Deitel interrupt 
processing with the kernel function call. Nothing in Deitel 
suggests that there might be any circumstance in which its 
interrupt processing could be interrupted based on another 
complication. Deitel specifically teaches that additional 
interrupts are disabled during interrupt processing, 
therefore, clearly there is no suggestion in Deitel of 
monitoring for a complication during interrupt processing. 

Claims 5 and 6 involve the passing of a specific 
identifier not disclosed or suggested by Deitel: "an 
identifier indicating the amount of kernel function call 
execution that had been completed at the time the 
complication was detected ." Since Deitel 's interrupt 
processing cannot be interrupted by a complication, there is 
no suggestion that there is any need to identify the amount 
of interrupt processing that had been completed at the time a 
complication was detected. 

In summary, claims 1, 2, 5 and 6 contain methods not 
taught or suggested by the Deitel reference and the Examiner 
is respectfully requested to reconsider the rejections of the 



claims* If any additional fee is required by the filing of 
this amendment, the Commissioner is hereby authorized to 
charge Deposit Account 04-0165. 
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